Security in the context of computing devices is still gaining importance. Was the subject at one time only relevant to servers, now it has spread via the desktop to all kinds of processor-based devices. Computing elements are becoming small, disseminated, unsupervised, and physically exposed. In addition to conventional computers, many devices nowadays include a processor whose software can be changed. For example, PDAs, smart-phones and satellite navigation devices can download application programs that can be run on the operating system of the device. At the same time the number of applications running on a given device is increasing, as is the number of suppliers, which makes it ever harder to say something definite about the security level. Against this background of an increasing number of different security sensitive platforms running more and more software, the liabilities are increasing. Some of the applications may also operate on protected content, e.g. audio tracks, movies, talking books, etc. The cost of security breaches is thus increasing as more sensitive information and responsibilities are put on the devices. Typically such content is protected using Digital Rights Management (DRM) system. The popular DRM applications like WINDOWS MEDIA DRM or APPLE's FAIRPLAY, which are in use for music and/or video downloads enforce rules of use on a customer, e.g. on which type or number of platforms the content may be rendered; a maximum duration for which the content may be rendered, restrictions on a number of copies that may be made, etc. A company that implements such a DRM system (supplies a software media player or a portable device with such a media player) may have to agree to robustness rules which typically demand minimum security levels, e.g. to ensure that the implementation can not be compromised with simple means. There can be stiff penalties for when security is broken.
Frequently, protections can be bypassed because attackers have full control of the operating systems and applications such as DRM players or mobile agents. To address these emerging threats, there have been significant efforts to build a secure computing platform that enables users to authenticate the platform and its software. The Trusted Platform Module from Trusted Computing Group, Next Generation Secure Computing Base from MICROSOFT, and TRUSTZONE from ARM all incorporate authentication mechanisms. If a DRM mechanism is implemented on these secure platforms, a content provider can encrypt its protected content just for a specific device executing trusted DRM software. While these systems can detect attacks that tamper with the operating systems or user applications, they cannot protect against physical attacks that tap or probe chips or buses in the system. In G. Edward Suh e.a. “Aegis: A single-chip secure processor”, Information Security Technical report (2005) 10, 63-73, Elsevier a single-chip secure processor called AEGIS is introduced. In addition to mechanisms to authenticate the platform and software, the processor incorporates mechanisms to protect the integrity and privacy of applications from physical attacks as well as software attacks. Two key primitives, namely, Physical Random Functions (usually referred to as PUFs) and off-chip memory protection enables the physical security of the system. The AEGIS processor is able to shield against software and physical attacks by protecting a program before it is executed, protecting it during execution, and protecting it during processor mode transitions. When an application is initially run, the processor uses a program hashing technique to verify that the program was not corrupted while it was held in unprotected storage. During execution the processor uses integrity verification, memory encryption, and access permission checks to guarantee security under four different secure execution modes. For the memory encryption, the AEGIS processor uses a one-time-pad encryption scheme determined by choosing a random encryption/decryption key. The AEGIS processor also allows users to authenticate the processor and software. For this purpose, each processor has a unique secret key securely embedded using a PUF. For example, each processor can have its own private key whose corresponding public key is known to users. Then, the processor can sign a message with the private key to authenticate itself to the users. In order to support software authentication, the processor combines program hashes with a digital signature as in Microsoft NGSCB or TPM. When the operating system starts and enters a secure execution mode, the processor computes the cryptographic hash of the trusted part of the operating system, which is called the security kernel. This program hash is stored in a secure on-chip register, and is always included in the signature. Therefore, when users verify a signature from the processor, they know that the message is from a particular security kernel running on a particular processor. The security kernel provides the same authentication mechanism to user applications by computing their hashes when user applications enter a secure computing mode.
Another approach to make it easier to comply with the security requirements is virtualization. In the actual machine a ‘virtual machine’ (VM) is created that runs one or more security sensitive applications. The number of virtual machines supported on a single CPU can vary, for example for each user a respective VM can be created, or for each application, or even for parts of applications. The underlying idea of increasing security by using VMs is that security problems will be contained to the virtual machine involved. A malicious program part (e.g. application) is constrained to the virtual machine within which it is executed and can not influence any program part outside the involved VM. One well-known virtual machine is JAVA. JAVA applications run inside a sandbox, which shields them from other virtual machines running on the device.
But even with virtualization there remain problems. First of all, an application running inside a VM may try to ‘break out’. This can happen either because of bugs in the virtualisation software, or because of features of the platform that may be inherently hard to virtualize (for instance it may be difficult to virtualize certain shared hardware components, such as I/O ports). The second problem is that, for legal and liability reasons, guarantees must be given on the quality of the virtualization, which can be hard for a large software program. Finally creating virtual machines that are fully secure is hard and expensive.